Cheating is rampant in online multiplayer games. Such cheating is unsurprising for persistent-world games since players accrue value for their performance, which may sometimes result in monetary prizes. However, with respect to short-term action games in which the payoff is merely bragging rights, there is also significant cheating. The prevalence of such cheating threatens to erode players' confidence in the integrity of game systems, which could lead to a contraction in this rapidly growing industry.
For personal computer (PC) games, cheating has proven to be an extremely challenging problem since players can arbitrarily modify game programs that run on their PCs. However, for console games, the problem is more tractable, as proprietary platforms can prevent loading and executing arbitrary code. In addition, modern consoles encrypt the messages they send to each other, which generally prevents a would-be cheater from observing message contents and from injecting forged messages.
Despite these safeguards, players can and do cheat in console games. For instance, players can drop or delay network packets, which is particularly effective if done selectively, as when applied only to players on an opposing team. In addition, players can launch denial-of-service (DoS) attacks against their opponents' machines.
Online console games can be broadly divided into two classes, according to their communication structure: client/server and peer-to-peer. Most online console games (e.g., Halo 3©, Gears of War©, Call of Duty IV©, etc.) employ a client/server (C/S) architecture. In C/S games, one machine acts as a server, and all others act as clients. The server maintains all of the game's state, wherein game play is temporally divided into a sequence of frames, each of which is typically around 50 ms in length. During each frame, every client sends a message to the server to describe the actions of the client's local player. The server processes the messages it receives, updates the game state, and sends messages back to the clients to inform them of the new state. The server machine also acts as a client for its own player, but communication between this client and the server does not go over the network. To be eligible to participate in online gaming, machines must meet a minimal set of performance requirements specified by the game title. To be selected as a server, there are often additional requirements, such as higher network bandwidth and a routable IP address.
For online games utilizing a peer-to-peer (P2P) architecture (e.g., Perfect Dark Zero©, Call of Duty III©, etc.), all machines participating in a particular game collectively maintain the game's state. On each frame, every peer sends information about its portion of the state to other peers. Depending on the game, each peer might send information to every other peer in the game, or only to a subset thereof. The latter situation arises in games that employ area-of-interest filtering, wherein a player's machine only receives information that is currently relevant to the player.
With respect to latency, C/S and P2P games generally have similar network-latency requirements. Several user studies have investigated the effect of network latency on the performance and playability of online games. The bound on tolerable latency varies by game category, wherein the most stringent requirements are generally for first-person shooter games, which become unplayable when latencies start exceeding 150 ms.
Although most state-of-the-art game consoles implement sophisticated security features, they still expose a threat model that admits several powerful attacks. For instance, in modern game consoles such as PlayStation3© and Xbox 360©, security features generally focus on averting exploits that were widely observed on earlier console systems. These earlier exploits took advantage of two main attack vectors: First, players were able to observe and modify the code running in their local consoles; second, players were able to intercept, decode, and inject packets into the data streams to and from other consoles.
To address the first attack vector, modern console systems prevent loading and executing arbitrary code. Preventing such loading and executing of code is usually accomplished through a combination of cryptographic verification of application binaries, process and memory isolation, and hardware-based management of encryption keys.
For the second attack vector, consoles encrypt all game-critical communication with each other, using single-use session keys, symmetric-key encryption, message authentication, and cryptographic nonces. This encryption prevents an attacker from observing the content of messages. It also prevents an attacker from forging new messages or replaying messages into the communication stream.
For most modern game consoles, it is thus fairly safe to assume that game consoles will run the code they are supposed to, that players will not be able to observe the content of game-critical messages, and that packets received by a console were legitimately generated by another console. However, despite these assumptions, modern consoles are still vulnerable to several powerful attacks.
An exemplary threat model 100 for one such attack is provided in FIG. 1, wherein attackers are players in a game. Here, although the attackers may not have access to the internal state of their consoles 120, they can place packet sniffers/filters 130 between their consoles 120 and the network 110, as shown. The packet sniffers/filters 130 cannot decrypt the payloads of network packets, but they can observe packet header fields, packet sizes, and the relative timing of packets. The packet sniffers/filters 130 could be general-purpose PCs, making them arbitrarily programmable. Thus, attackers can configure their sniffers/filters 130 to drop or delay packets based on any observable property of the packet.
Multiple attackers may also collude by sharing their independently observed information. For instance, Player 1 might observe properties of her outgoing packets and send this information to Player 4 so that he can test his incoming packets against these properties. Player 1 can even delay her outgoing packets so that her information has time to reach Player 4 before her game packets do. Player 1 can also alter her data stream to make it more readily identifiable to Player 4. For instance, Player 1 can drop outgoing packets in a particular pattern, or she can alter the timing of packets.
Threat model 100 thus provides a model in which any of several powerful attacks may be launched. For instance, an attacker may launch a denial-of-service (DoS) attack in which the attacker floods an opponent's machine with traffic. Such an attack requires merely knowing the IP address of the attack target.
Other attacks generally fall into the class of dropping or delaying packets. In C/S games, the crudest form of such attack is standbying, which involves putting one's DSL or cable modem into standby mode to block traffic to and from all clients. By standbying at critical moments in the game, the player at the server can continue to strike opponents while other players are frozen. Because standbying is far from subtle, it is readily detectable by in-game traffic auditing. However, by applying traffic analysis, the attacker can stay under the auditing radar by surgically forcing packet drops on particular players, such as the opponent currently being fought. Also, a server-side attacker can help particular players (e.g., teammates or friends) by perturbing packets only to or from players other than the chosen ones.
Because games often “trust” clients, particularly in light of game consoles' security features, such games may be particularly vulnerable to attacks from clients. For instance, although clients know that the server is the source of all inbound traffic, they can still gain leverage by inferring the likely type of a packet. Thus, clients can drop inbound packets with undesirable consequences, such as those indicating damage. Here, it should be noted that, because each peer in a P2P game is effectively part of the server as well as a client, all of the above attacks have direct analogies in the P2P setting.
A potential defense to the aforementioned attacks may include anonymizing network traffic, thus preventing traffic analysis from revealing the sources and destinations of game packets. For non-gaming applications, a well-known mechanism for performing such anonymization is onion routing. In an onion routing scheme, each packet is encrypted in multiple layers and forwarded through a series of relays, each of which peels off one cryptographic layer. Unfortunately, onion routing incurs excessive latency, which may be adequate for applications insensitive to latency, but is intolerable for high-speed online games.
Accordingly, there is a need for a method and system for thwarting traffic analysis in online games. Such a need includes a need for preventing inspection of data packet headers, data packet size, and data packet timing, in a manner that conforms to the latency requirements of online games.
The above-described deficiencies of current techniques are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with conventional systems and corresponding benefits of the various non-limiting embodiments described herein may become further apparent upon review of the following description.